1. Field of the Invention
The present invention relates to use of Network Address Translation (NAT) by private networks; more particularly, the present invention relates to peer-to-peer communications between Internet Protocol (IP) endpoints in a network having at least one NAT device for translating a private address realm of the network to a shared address realm.
2. Description of the Related Art
The growth of the Internet in the 1990s and 2000s has rapidly reduced the number of available public IPv4 addresses. In an effort to reduce the rate of depletion of the public IPv4 addresses, the Internet Assigned Numbers Authority (IANA) has reserved prescribed blocks of IP address space for private internets, namely 10/8 prefix (a single Class A network number), 172.16/12 prefixes (a set of 1 contiguous Class B network numbers), and 192.168/16 prefix addresses (a set of 256 contiguous Class C network numbers), the numeral following the “/” indicating the relevant number of most significant bits of the 32-bit IP address. Hence, an enterprise (i.e., an organization implementing its own IP-based private network) that utilizes these reserved blocks of IP address space can do so without any coordination or permission from the IANA or any Internet registry.
However, such private addresses are unique only within the enterprise, or set of enterprises which choose to coordinate address assignments within this address space. Hence, since these private addresses are not globally unique, the hosts (i.e., end nodes) of the private network cannot use their respective assigned private addresses within the public address realm (i.e., the Internet). Consequently, once the enterprise attempts to connect to the Internet to achieve Internet connectivity, the enterprise needs to change (i.e., renumber) the assigned IP address used by the private host during access of the public network.
Hence, network administrators have been deploying Network Address Translation (NAT) devices referred to as NATs. NATs perform a Layer-3 translation of IP-Addresses, so that public Internet addresses map to private IP addresses, as described in detail by the Request for Comments 1918 (RFC 1918), published by the Internet Engineering Task Force, available on the World Wide Web at www.ietf.org. This mapping has allowed enterprises to map a large number of private addresses to a limited number of public addresses, thus limiting the number of public addresses required by Internet users.
NAT usage has introduced many problems, most of which are well documented in RFC 2993, published by the IETF. The most basic problem introduced with the usage of NATs is the inability for peer-to-peer applications to function. Unlike client-server applications, peer-to-peer applications, for example Voice Over IP (VoIP) applications or gaming applications, function with the assumption that the basic End-to-End Model of IP routing as defined in RFC 2775 will succeed in transporting IP Packets. For example, the End-to-End Model assumes uniform addressing and transparency between endpoints, where “transparency” refers to the original Internet concept of a single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered. Hence, the End-to-End Model assumes that the endpoints are the only places capable of correctly managing a data stream, and that the network should be a simple datagram service that moves bits between these points.
In particular, both peers in a peer-to-peer application need to be capable of sending IP packets directly to each other; in other words, each peer being assigned a corresponding IP address will receive IP packets generated by the other peer when that corresponding assigned IP address is specified within the destination address field of the IP packets. The use of NATs, however, affects the transparency of end-to-end connectivity for transports relying on consistency of the IP header, and for protocols which carry that address information in places other than the IP header.
A simple set of protocols have been defined that allows a peer (or both peers) in a peer-to-peer application to dynamically obtain the temporary usage of an IP address that can be used by the other peer as the destination of IP packets. This temporary IP address must be obtained from the IP address realm where the other peer also has been assigned an IP Address (via any normal assignment mechanism, including the possibility that it is also temporarily assigned with these protocols). These protocols are called Simple Traversal of UDP Through Network Address Translators (STUN) and TURN (Traversal Using Relay NAT), both of which are described in Internet drafts, see e.g., draft-ietf-midcom-stun-03.txt at the IETF website www.ietf.org.
In particular, STUN enables applications behind a NAT (i.e., served by a NAT) to discover the presence and types of NATs, and determine the public IP addresses allocated to them by the NAT. The STUN protocol utilizes a STUN client connected to the private network (i.e., behind the NAT), and a STUN server in the public Internet. The STUN client sends a binding request to the STUN server to determine the binding (i.e., address translation) utilized by the NAT; the STUN server examines the source IP address and UDP port of the request, and copies the source IP address and UDP port into a response that is sent back to the client. The STUN client can then compare the response with its own IP address to determine if it is behind a NAT.
In addition, since the STUN server is on a public Internet and the IP address and UDP port is in the body of the response, any host on the public Internet can use the pubic address to send packets to the application that sent the STUN request. The type of NAT(s) between the STUN client and STUN server will determine if the STUN client that sent the STUN request will receive the aforementioned packet as is described in the STUN Internet draft. Typically the public IP address is “published” on a server providing a Name to IP address mapping such as a SIP Proxy Server or a Domain Name Server. Thus a peering host (e.g., a Voice over IP telephony application) can locate the public IP address using prescribed query techniques, including Domain Name Server (DNS) queries.
Hence, a Name to IP address mapping service can be used by another device with access to the public Internet wishing to communicate with the STUN client. Hence, one or both of the peers will be able to obtain an interworkable address that is located in the same (shared) IP address realm beyond the NAT and used by the STUN server, where the interworkable addresses are routable using the End-to-End Model of IP.
A substantial disadvantage of using these interworkable addresses in the shared address realm, beyond utilizing a STUN server, is the requirement for IP packets flowing between the peer to always traverse the same shared IP address realm beyond the NAT. Hence, the IP packets may need to traverse multiple layers of NATs in order to reach the shared IP Address Realm having a STUN server reachable by both peers. Consequently, the peer-to-peer traffic between the endpoints are subject to the constraints and limitations of each NAT traversed by the peer-to-peer traffic. Such constraints and limitations may be substantial for NATs implemented using dial-up connections, or NATs burdened by limited processing resources or additional network processing requirements (e.g., executing firewall operations, etc.). Moreover, even if the two endpoints are within the same private network, the topology of the private network may prevent existing discovery resources from discovering that both endpoints are within the same address realm, requiring the two endpoints to rely on the STUN servers in the public address realm via the NAT.